It seems like error states for missing value and malformed input are not shown:

I understand that it would be a difficult task to show the time in the users local time zone, however what about setting the timeCaption property on the picker to "Time (UTC)" to emphasize this? Otherwise I'm concerned this way of setting the time makes it very easy for users to miss they need to convert to UTC before selecting the time:

It seems like error states for missing value and malformed input are not shown:

@flash1293 looks like you're using the Bing Ads source connector, right? That connector spec unfortunately doesn't specify a pattern for the start_date:

"reports_start_date": {
  "type": "string",
  "order": 5,
  "title": "Reports replication start date",
  "format": "date",
  "default": "2020-01-01",
  "description": "The start date from which to begin replicating report data. Any data generated before this date will not be replicated in reports. This is a UTC date in YYYY-MM-DD format."
}

Which is what we depend on to do regex validation here when generating the yup schema. So any old string can be passed in 😕 Unfortunately quite a few connector specs are missing pattern or format: date | date-time which means the field won't be validated or the datepicker won't be shown respectively.

Should we auto-add this pattern if it doesn't exist or will it break things? If it's too dangerous to do it, we should probably extend the SAT to cover this situation (out of scope for this PR I'd guess)

Should we auto-add this pattern if it doesn't exist or will it break things? If it's too dangerous to do it, we should probably extend the SAT to cover this situation (out of scope for this PR I'd guess)

I'm not sure I have enough context on the date types (there are five) to know if this would break anything - probably not? But my feeling is that keeping the connector definition specification as the source of truth for validation is the best approach. I'd rather advocate for consistency in the connector specs than patching missing fields on the frontend.

+1 to the timeCaption suggestion

Yeah I think the problem with trying to enforce the regex pattern in the frontend if it is missing on the connector spec is that different connectors may require different timestamp formats, so we can't implement a blanket logic to cover all connectors correctly. Though @sherifnada or @girarda correct me if I'm wrong here - I assume some timestamp formats are API-specific, but if it actually can be made consistent across all APIs that would be great

if it actually can be made consistent across all APIs that would be great

+1 for that, I think going with the current logic for now and extending the SAT is a good approach to get to a clean state without breaking things in the meantime.

@flash1293 thanks for the idea about adding Time (UTC)! Just pushed that here.

if it actually can be made consistent across all APIs that would be great

agreed. But this will take a little bit longer than we want to merge this PR :) so I think we shouldn't assume the regex on the frontend